Digital Certificates (“certificates”) are critical to Internet security. Certificates are electronic files that make it possible for information to be transferred privately over the Internet. Such information may include personal identifying information, individually identifiable health information, proprietary information, and confidential information. Certificates provide peace of mind to Internet users by verifying the identity of the destination to which a user is sending sensitive or confidential information. Digital Certificates also may be used in a wide variety of other computer transactions to verify identities, ensure privacy, and otherwise secure the transaction.
Certificates are issued by Certificate Authorities (“CA”s), or by trusted intermediaries of CAs. As used herein, “CA” may also include an intermediary of a CA. An intermediary CA of a root CA is trusted and operated by the root CA, and issues certificates on behalf of the root CA. A CA issues a certificate, encrypted with the CA's private key, to a requesting website operator after the CA has taken measures to verify the identity of the website operator. The issued certificate includes the website's public key. The website is the only entity that knows the private key associated with the website's public key.
When an Internet user visits the website, the website presents its certificates to the user to verify its identity to the visiting Internet user. When presented with a certificate, an Internet user, generally through a browser such as Internet Explorer, Chrome, or Firefox, consults its list of trusted CAs. If this list of trusted CAs includes the CA that allegedly issued the certificate (i.e., the CA identified in the certificate as the alleged issuer of the certificate), then the Internet user will verify the authenticity of the certificate by (1) using the CA's public key to decrypt the hash included with the certificate (which is the hashed certificate data encrypted with the CA's private key), (2) generating a hash from the data in the certificate, and (3) confirming that the hashes resulting from the first two steps are the same. If these two hashes match, then the Internet user will generally conclude both (1) that the certificate was actually issued by the issuer identified in the certificate, and (2) that the website (or other resource) is operated by the entity identified in the certificate.
Now the Internet user and the website operator agree on a symmetric key to user for a particular communication session. The Internet user reads the website operator's public key, which is included as a field in the website's certificate. The Internet user generates a symmetric key, uses the website's public key to encrypt the symmetric key, and sends the encrypted symmetric key to the website. The website uses its private key to decrypt the encrypted symmetric key received from the Internet user. At this point, the Internet user and website have completed a “handshake,” and both know an otherwise secret symmetric key. The Internet user and website use this symmetric key for encrypting and decrypting communications with each other.
One shortcoming in this public key infrastructure is that the operator of a website or other network server or Internet server is fully dependent on the CA for all modifications to a certificate, even modifications that are trivial and/or secure. For example, for a website to edit or update its subject name in its certificate requires the website to obtain a new or modified certificate from a CA. It would be beneficial and more efficient if a website, Internet server, or other network server could update at least a subset of certificate fields without CA intervention.
Another significant concern with the public key infrastructure network security vulnerabilities resulting in the compromise of a website's private key(s). The Heartbleed attack highlighted this vulnerability. The Heartbleed virus exploited a vulnerability in the public key infrastructure (sometimes referred to loosely as “SSL”) to scan the memory contents of network servers, such as webservers, to find and compromise private keys. These compromised private keys could then be used to masquerade as the owner of the domain or for other nefarious activities. Because the private keys secured the certificates used by websites, webservers, and other servers, the administrators of these servers had to revoke their certificates, and then reinstall their certificates, resulting in many lost operational hours for their servers.
Some users of digital certificates have sought to mitigate potential damage from Heartbleed or similar breaches by frequently reinstalling new certificates (called Short-Term Certificates). Such an approach may reduce the risk of serious server damage and data loss if a private key is lost. The short-term-certificates scheme assumes, however, that fields are unmodifiable because of the certificate's signature.
What is needed is an approach, system, and/or method whereby (1) a website, Internet server, or other network server may modify some or all certificate fields without CA intervention and (2) a primary private key is not stored in the memory of a host computer or server.